Immeasurable gains in technology offered in personal computers ("PCs") have allowed PCs to assume roles performed in the past only by mainframe or minicomputers. Many companies and individual users rely solely on commercially-available PCs to meet their information processing needs. Thus, it is vital that their PCs perform reliably. If, however, a PC experiences a fault, it is equally vital that the PC communicate existence of the fault. This informs the user of a need to repair the fault so the PC can return to active service. For computer systems in general, it is most helpful for the computer system to provide an indication of the specific location and nature of a fault to help the user quickly isolate and economically repair the fault. To that end, current PCs are typically equipped with some form of internal diagnostics, the purpose of which is to detect and isolate component faults within the PC architecture.
Diagnostic routines consist of a series of instructions executed by a central processing unit ("CPU") within a computer system to allow self-diagnosis. In the past, some computers have been provided with diagnostic routines that test and report on the operational status or functionality of components within the computer, allowing an interested party to repair or replace components that are not functioning to the desire degree.
Diagnostic code is sometimes stored on disk and retrieved therefrom for execution by the CPU (so-called disk-based diagnostics). One advantage of disk-based diagnostics is that disks provide a relatively large area in which to store code, allowing diagnostic routines to be relatively sophisticated and thorough in their testing and reporting. Unfortunately, diagnostic routines are frequently invoked when components in the computer are not completely functional. To successfully retrieve and execute disk-based diagnostics, the following components must be fully functional: CPU, address and data buses, bus controller, disk drive controller, disk drive and keyboard. If any significant information is to be relayed back to the user, a display device or a printer and their associated interface hardware must also be functional. It is apparent therefore that if any one of these components is not fully functional, the diagnostics may not execute or interact with the user properly.
One solution to the above-noted problem with disk-based diagnostics was solved in part by embedding diagnostic code in solid state, non-volatile memory within the computer. Thus, read-only memory ("ROM"), for instance, was employed to store diagnostic code as firmware. One type of embedded diagnostics is power-on self-test ("POST") diagnostics, generally stored in basic input-output system ("BIOS") ROM in PCs. POST is a series of tests that the computer performs on its components each time the computer is turned on. POST begins by reading system configuration information that has either been hard-wired or stored in non-volatile memory. It then checks random access memory ("RAM") by writing to and reading from the RAM to insure proper operation. POST next examines the disk drives to confirm that they match the system configuration information. Lastly, POST initiates the loading of the operating system, "booting" the computer. Failure during execution of POST indicates presence of a fault within the computer. However, POST does not always provide a clear indication of the specific nature of the fault. Instead, the user must run diagnostic software to further isolate the fault. Each phase of the POST routine involves a check of the computer system's major components: the CPU, the main and cache memory subsystems, the video subsystem, the buses and certain peripherals, such as the hard and floppy disk drives.
In contrast to disk-based diagnostics, embedded (or ROM-based) diagnostics require the following components to function: CPU, address and data buses and bus controller. Again, if any significant information is to be relayed back to the user, a display device or printer and associated interface hardware must also be fully functional. Although ROM-based diagnostics are typically required to fit within a smaller space and therefore do not have the luxury of being as thorough in testing as disk-based diagnostics, it is apparent that fewer components need be functional to successfully retrieve and execute embedded diagnostics.
Serial No. (DC-00328) discloses a system for loading compressed embedded diagnostic routines. Given the relatively limited space within non-volatile memory, embedded diagnostic routines decompressed and paged into volatile memory as required enjoy a distinct advantage over more traditional diagnostic processes. The embedded diagnostic routines allow local diagnosis of faults as severe as non-bootable faults (defined as faults so critical that the PC is unable to boot and operate under its normal operating system).
As PC systems become more and more complex and as users increasingly come to rely on the services of skilled technical personnel to maintain and repair their PCs, it is growing less favorable to force the user to diagnose PC faults. The general direction in the development of diagnostic software systems to this point has been to isolate the user somewhat from the intricate and technically complex operations of diagnostic routines by presenting a user-friendly interface written in clear English text and presented in an aesthetically pleasing manner. However, the user is still forced to (1) interact with the diagnostic routines, (2) report findings to a remote technician and (3) take actions under direction of the remote technician. This usually results in an iterative approach, wherein the user's inexperience forces the remote technician to proceed laboriously through the diagnostics process, considering all possibilities. This is in contrast to the more efficient process an experienced technician undergoes when directly in control of the PC. This is because the technician's experience allows faster diagnosis. The user, who in general has no interest in being involved with the diagnostics process, is in fact both the focus and the bottleneck.
There are three possible solutions to the above-noted problem. First, the technician can travel to the computer to physically sit in front of it. However, this is a great waste of the technicians' time and frequently removes the technician from technical resources, such a repair manuals and online help, that are available at the technical support center. Second, the PC can be supplied with dedicated diagnostic hardware. This is not only expensive, rendering the PC as a whole relatively noncompetitive in terms of its price, but is frequently a wasteful duplication of hardware, as the diagnostic hardware comes into use only infrequently. Third, the remote technician can perform remote diagnostics via communications software running in conjunction with traditional disk-based diagnostics, all executing under the PC's normal operating system. Unfortunately, as detailed above, this third option is only available when the PC is substantially operable and bootable and not when the PC has suffered a non-bootable fault.
A system and method for allowing remote diagnosis of PCs, even those suffering non-bootable faults, by a remote technician that are cost and hardware efficient are acutely needed in the art. Unfortunately, remote diagnosis requires certain components within the PC to be fully functional, namely a modem and its associated interface hardware, such as a universal asynchronous receive/transmit module ("UART"). More conventional prior art, disk-based methods of accessing and using the modem require many hardware components and access to the PC's normal operating system to function as detailed above. Accordingly, there is, in particular, a need in the art for a method of providing for remote diagnosis in PCs and the like that requires a minimal amount of fully functioning hardware and software to operate so that even non-bootable faults can be remotely diagnosed.